Public computer networks and local area networks are now widely used for communication of a variety of information among content sources, such as server computers, and content consumers, such as end-user computers that act as clients of the server computers. The information communicated from a content source to a content consumer may include text, music, video, telephone calls, digital files, or other information that is broadly termed “content.” The networks that carry such content may include local area networks, wide area networks, virtual private networks, or the worldwide interconnected internetworks known as the Internet.
Several prior content distribution approaches are known involving end-user computers, server computers, and public networks. In this context, an end-user computer is a computer system whose primary function is to serve a single local human user at one time through an interface device such as a keyboard, trackball, mouse, etc., and includes a personal computer, Internet appliance, personal digital assistant, etc. The end-user computer executes a Web Browser, which is one or more software elements that communicate with Web servers using the Hyper Text Transfer Protocol (HTTP). The browser can download and render documents that are formatted in Hyper Text Markup Language (HTML) and Extensible Markup Language (XML), and supports hyper-linking, among other features. Examples of such Web browsers include Microsoft Internet Explorer and Netscape Communicator.
The term “server computer” refers to a computer system whose primary function is to serve large numbers of remote end-user computers through programmatic interfaces such as multiplexed network connections. These systems are typically more expensive and more powerful than end-user computers, and are often professionally managed. End-users do not interact directly with server computers.
The term “public network” refers to one or more local area networks, wide area networks, virtual private networks, or the worldwide interconnected internetworks known as the Internet. Nodes connected to such networks communicate using Transmission Control Protocol/Internet Protocol (TCP/IP).
In one content distribution approach, one or more end-user computers each receive content over a public network from a server computer that is logically in a central location with respect to the end-user computers. An end user selects the content in which the end user is interested. The content is organized in channels. Each channel comprises a stream of content from a given server computer that is updated on demand or at regular intervals. Selecting a channel is termed subscribing to the channel. A user may select channels by submitting an HTML form or clicking on a link through a Web browser. The Web browser then transmits the selection information to the server computer where it is stored.
Given the list of channels selected by the end user, an aggregator fetches the latest channel content from the various channel sources which may be local to the end-user computer or on a remote server computer. This step may be performed asynchronously from end-user interaction, with the fetched content being cached at the server computer. The aggregator may be combined with a Web server and implemented as an Aggregator/Web Server. The Aggregator/Web server is software executed on one or more server computers and including a Web server that serves files using HTTP. Examples of such Web servers include Apache, Microsoft Internet Information Server, and Netscape Enterprise Server. Web servers typically require specialized expertise to configure and maintain, and may interact with other server software that aggregates raw data from local and remote databases and server computers to generate Web documents, which are then served to end-user computers by the Web server.
The end user then organizes the content into a particular spatial layout. In other approaches, this typically involves choosing a vertical ordering within one of a fixed number of columns. The end user performs this step through the Web browser, which transmits the information back to the server computer where it is stored. Using the content fetched from channel servers and the organization specified by the end user, the server computer synthesizes an HTML document. The synthesized HTML document is delivered over a network connection to the Web browser on the end-user computer for presentation to the end-user. Examples of commercial services that embody this approach are My Yahoo!, Yodlee (available at the Web site yodlee.com), and Epicentric.
A second approach focuses on the use of a proprietary content viewer. In this approach, an end user selects the content in which the user is interested, by interacting directly with a content viewer or Web browser to make selections. The selections are stored in the content viewer on the end-user computer. The Content Viewer refers to proprietary software that is typically owned by a third party. The Content Viewer runs on an end-user computer and communicates with server computers using HTTP and other standard or proprietary protocols. In other approaches, the content viewers may be implemented as graphical toolbars that dock to the edges of the end-user computer's screen or to a Web browser. In particular, a content viewer does not serve content to standard Web browsers over HTTP or TCP/IP, and displays content in a proprietary fashion.
Given the list of channels selected by the end user, the content viewer fetches the latest channel content from the various content sources. This step may be performed asynchronously from end-user interaction, with the fetched content being cached at the end-user computer. The end-user then organizes the content into a particular spatial layout. In other approaches, this typically involves choosing a button or menu position on a toolbar. The end user interacts directly with the content viewer to organize the content. The organization is stored in the content viewer. Using the content fetched from channel servers and the organization specified by the end user, the content viewer synthesizes the content into its proprietary display format. The synthesized content is then presented to the end user though the content viewer's proprietary interface. Examples of commercial services that use this approach are PointCast and Snippets.
Based on the foregoing, there is a clear need for improved ways to deliver content over a public network. For example, in prior approaches, remote intermediary servers are required for content to be delivered to end-users. Thus, there is a need for a way to eliminate such intermediary servers.
Further, in other approaches, a proprietary content viewer is sometimes required. There is a need for a way to enable an end-user to receive channel content without having to obtain, load, install or use a proprietary content viewer.
Also, in prior approaches, an end-user's content selection choices generally must be delivered over the Internet to the intermediary server, exposing the end-user to eavesdroppers. There is a need for a way to communicate channel choices that does not require selection choices to be delivered over the Internet, enhancing privacy.
Also in prior approaches, the synthesized Web page must be delivered to the end-user computer over his or her Internet connection, which is often slow and leads to high page load latency. There is a need for a way to reduce page load latency. In other approaches, if the intermediary server is under heavy load, performance for each end-user diminishes. There is a need for a way in which performance remains constant regardless of the number of global users of the personal server. Further, in other approaches, if the intermediary server is out of service, no end-user can access her page. There is a need for a way to ensure that a page of an end-user is unavailable only when the computer of the end-user is out of service.
In still other approaches, if a channel provider server computer is out of service, the channel raw data stream is unavailable. There is a need for a way to distribute channel raw data streams over the Internet's e-mail infrastructure, eliminating the problem of a single point of failure. Yet another problem of past approaches is that channel publishing requires expensive hardware, a dedicated connection to the Internet, and expertise in configuring and maintaining software. An approach that avoids these requirements is highly desirable.
Another problem of conventional online processing relates to name resolution. In one prior approach, name resolution is accomplished using the following process. The end-user enters a URL into a TCP/IP application, such as a Web browser. The application must first resolve the host name in the URL to an IP address. To do this, the browser sends a request to the TCP/IP networking stack in the operating system on which the Web browser is running. The TCP/IP stack may have the translation cached, in which case it can reply immediately to the Web browser.
Alternatively, if the translation is not cached, the TCP/IP stack makes a request to an external DNS server. The external DNS server resolves the name. This step may include contacting other servers. The DNS server sends the translation back to the end-user computer's TCP/IP stack. The TCP/IP stack sends the translation back to the TCP/IP application, which then proceeds to make the connection using the IP address.
Based on the foregoing, there is a clear need for an alternative private naming system on the Internet. In prior approaches, using an alternative naming system other than DNS requires a modified Web browser. There is a need for an approach that provides alternative naming with any browser, or any other TCP/IP application.
Further, in other approaches, alternative naming requires a centralized server to maintain name mappings. There is a need for an approach in which no such centralized server is required.
In still other approaches, alternative naming is global, and does not allow two different users to use the same name to refer to different addresses. There is a need for an approach that permits two different users to use the same name to refer to different addresses.
Another drawback found in current network computing approaches relates to security control over applets that execute within a “sandbox” environment, such as Java® applets.
A document that is delivered to a Web browser may include one or more embedded applets. In general, an applet is a relatively compact executable program that is received over a network and executed locally at an end-user computer under the control of a local interpreter or virtual machine. The Java® language, for example, may be used to write applets that are communicated from a server over a network to a client computer. A Java Virtual machine executes the applets. The Java Virtual Machine typically is integrated with a client computer network application such as a Web browser.
A security concern associated with applets is that an applet received from an untrusted server may attempt to cause the client computer to carry out unauthorized operations, such as deletion of files, reading configuration information or personal user data and forwarding such data to the server, etc. Accordingly, most Web browsers execute applets within a confined security domain or “sandbox” that restricts the resources that an applet can use. For example, a Web browser may restrict access of applets to security domains such as local persistent storage on the end-user computer and network connectivity to arbitrary servers on the Internet. Typically, the only external access allowed the applet is network connectivity to the server from which the Web browser loaded the applet.
Web browsers sometimes allow the security restrictions or boundaries of the sandbox to be configured by the operator, but with quite coarse granularity. For example, in one prior approach, the only permitted configuration operation is to enable or disable access to local persistent storage and network connectivity.
Based on the foregoing, there is a clear need for a method that provides for fine-grained security control over applets restricted to a sandbox.
A related problem of prior approaches is that an applet cannot access network servers other than the one from which it was loaded. There is a need for an approach that enables an applet to access any network server safely. Further, in prior approaches, applets cannot access local resources like other processes and local storage. There is a need to enable applets to safely have such access. Yet another related problem of past approaches is that cross-applet communication is dependent on Web browser support. There is a need for an approach that enables cross-applet communication regardless of the browser.
Yet another problem associated with online computing relates to targeted advertising on the Internet. In past approaches, targeted advertising requires disclosure of personal information of the end-user to the advertiser. Thus, there is a clear need for a method and apparatus for disclosure-free targeted advertising on the Internet. In particular, there is a need for an approach in which no disclosure is required, protecting end-user privacy.
Still another problem relating to online computing involves intercommunication between intermittently connected network nodes over e-mail infrastructure on the Internet. In past approaches, software processes running on intermittently connected nodes of a network have no way to communicate when no connection is present. Thus, there is a need for a method providing for such communication in the absence of a connection. There is a specific need for an approach that uses available network infrastructure to provide such communication, so that no additional infrastructure is necessary, and the system can be implemented with little cost.
Another problem associated with online computing relates to clipping Web pages and embedding them in other Web pages. In past approaches, clipping a Web page involves parsing its HTML code and directly embedding a subset of the HTML code into another page. There is a need for a method for clipping Web pages and embedding them in other pages that avoids disadvantages of this approach. In particular, there is a need for an approach in which HTML parsing is not required.